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Abstract. In many industries, the share of software components provided by 
third-party suppliers is steadily increasing. As the suppliers seek to secure their 
intellectual property (IP) rights, the customer usually has no direct access to the 
suppliers' source code, and is able to enforce the use of verification tools, and 
other measures for enhancing software quality, only by legal requirements. In 
turn, the supplier has no means to convince the customer about successful verifi- 
cation without revealing the source code. This paper presents a new approach to 
resolve the conflict between the IP interests of the supplier and the quality inter- 
ests of the customer. We introduce a protocol in which a dedicated server (called 
the "amanat") is controlled by both parties: the customer controls the verifica- 
tion task performed by the amanat, while the supplier controls the communica- 
tion channels of the amanat to ensure that the amanat does not leak information 
about the source code. We argue that the protocol is both practically useful and 
mathematically sound. As the protocol is based on well-known (and relatively 
lightweight) cryptographic primitives, it allows a straightforward implementation 
on top of existing verification tool chains. To substantiate our security claims, we 
establish the correctness of the protocol by cryptographic reduction proofs. 

1 Introduction 

In the classical verification scenario, the software author and the verification engineer 
share a common interest to verify a piece of software; the author provides the source 
code to be analyzed, whereon the verification engineer communicates the verification 
verdict. Both parties are mutually trusted, i.e., the verification engineer trusts that he 
has verified production code, and the author trusts that the verification engineer will not 
use the source code for unintended purposes. 

Industrial production of software-intensive technology however often employs sup- 
ply chains which render this simple scenario obsolete. Complex products are being 
increasingly assembled from multiple components whose development is outsourced 
to supplying companies. Typical examples of outsourced software components com- 
prise embedded controller software in automobiles and consumer electronics [1,2] as 
well as Windows device drivers [3, 4]. Although the suppliers may well use verification 
techniques for internal use, they are usually not willing to reveal their source code, 
as the intellectual property (IP) contained in the source code is a major asset for their 
company. 
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Fig. 1. A High-Level View of the Amanat Protocol 



This setting constitutes a principal conflict between the supplier Sup who owns the 
source code, and the customer Cus who purchases only the executable. While both 
parties share a basic interest in producing high quality software, it is in the customer's 
interest to have the source code inspected, and in the supplier's interest to protect the 
source code. More formally, this amounts to the following basic requirements: 

(a) Conformance. The customer must be able to validate that the purchased executable 
was compiled from successfully verified source code. 

(b) Secrecy. The supplier must be able to validate that no information about the source 
code other than the verification result is revealed to the customer. 

The main contribution of this paper is a new cryptographic verification protocol tailored 
for IP-aware verification. Our protocol is based on standard cryptographic primitives, 
and provably satisfies both the above requirements with little overhead in the system 
configuration. Notably, the proposed scheme applies not only to automated verification 
in a model checking style, but also encompasses a wide range of validation techniques, 
both automated and semi-manual. 

Our solution centers around the notion of an amanat. This terminology is derived 
from the historic judicial notion of amanats, i.e., noble prisoners who were kept hostage 
as part of a contract. Intuitively, our protocol applies a similar principle: The amanat is 
a trusted expert of the customer who settles down in the production plant of the supplier 
and executes whatever verification job the customer has entrusted on him. The supplier 
accepts this procedure because (i) all of the amanat's communications are subject to the 
censorship of the supplier, and, (ii) the amanat will never return to the customer again. 

It is evident that clauses (i) and (ii) above make it impossible for a human inspector 
to act as the amanat; instead, our protocol will utilize a dedicated server Ama for this 
task. The protocol guarantees that Ama is simultaneously controlled by both parties: 



Cus controls the verification task performed by Ama, while Sup controls the commu- 
nication channels of Ama. To convince Cus about conformance, the verification tool 
executed on Ama produces a cryptographic certificate which proves that the purchased 
executable is derived from the same source file as the verification verdict. 

To achieve this goal, we use public key cryptography; the amanat uses the secret 
private key of the customer, and encrypts outgoing information with this secret key. 
This enables the supplier to decrypt (and possibly block) all outgoing information, and 
simultaneously enables the customer to validate that the certificate indeed stems from 
the amanat. Thus, the amanat protocol achieves the two requirements above. Figure 1 
presents a high-level illustration of the protocol. 

Verification by Model Checking and Beyond. Motivated from discussions with in- 
dustrial companies (in both engineering and IT), our primary intention for the protocol 
was to facilitate model checking across IP boundaries. Thus, natural choices for the ver- 
ification tool on Ama are software verification tools from the SLAM, BLAST, MAGIC 
generation [5-7] as well as lightweight software verification tools [8]. 

The amanat protocol however is not restricted to model checking and static analysis, 
as the amanat can run any verification/validation tool whose output does not compro- 
mise the secrecy of the source code. For example, Ama can: 

1. apply static analysis tools such as ASTREE [9] and TVLA [10]. 

2. check the correctness of a manual proof provided by Sup, e.g., in PVS, ISABELLE, 
Coq or another prover [11]. 

3. evaluate worst case execution times experimentally [12] or statically [13]. 

4. generate white box test cases, and execute them. 

5. validate that the source code comes with a set of test cases which satisfies previ- 
ously agreed coverage criteria. 

6. check that the source code is syntactically safe, e.g. uses certain coding standards 
such as LINT. 

7. compute numerical quality and quantity measures which are agreed between Sup 
and Cus, e.g. nesting depth, LOC, etc. 

8. compare two versions of the source code, and quantify the difference between them; 
this is important in situations where Sup claims charges for a reimplementation. 

9. check if third party IP is included in the source code, e.g. libraries etc. 

10. ensure that certain algorithms are (not) used. 

1 1 . check that the source is well documented. 

12. ensure a certain senior programmer has put his name on the source code. 

13. validate the development steps by analyzing the CVS or SVN tree. 

14. ensure compatibility of the source code with language standards to facilitate porta- 
bility to other future platforms. 

We note that in all scenarios the code supplier bears the burden of proof: either the 
supplier has to write the source code in such a way that it is accepted by Ama as is, or 
the supplier has to provide auxiliary information (e.g. proofs, command line options, 
abstraction functions, test cases, etc.) which the amanat reads and evaluates together 
with the source code. In the latter case, the supplier helps the amanat to achieve a 
positive verification result without affecting the correctness of the amanat's verification 
task. 



Security of the Amanat Protocol. In Section 4, we present a cryptographic proof for 
the secrecy and conformance of the amanat verification protocol. Stronger than term- 
based proofs in the Dolev-Yao model, these proofs assure that under standard crypto- 
graphic assumptions, randomized polynomial time attacks against the protocol (which 
may involve e.g. guessing the private keys) can succeed only with negligible probabil- 
ity [14]. The practical security of the protocol is also ensured by the simplicity of our 
protocol: As the protocol is based on well-known cryptographic encryption and signing 
schemes, it can be readily implemented. 

The IP boundary between the supplier and the customer makes is inevitable that the 
amanat owns a secret unknown to the supplier, namely the private key of the customer; 
this secret enables the amanat to prove its identity to the customer and to compute 
the certificate. Consequently, the cryptographic proofs need to assume a system con- 
figuration where Ama can neither be reverse-engineered, nor closely monitored by the 
supplier. Thus, from the point of view of the supplier, Ama is a black box with input 
and output channels. For secrecy, the supplier requires ownership of Ama to make sure 
it will not return to the customer after verification. There are two natural scenarios to 
realize this hardware configuration: 

A Ama is physically located at the site of a trusted third party. All communication 
channels of Ama are hardwired to go through a second server, the communication 
filter of the supplier, cf . Figure 1 . 

While scenario A involves a trusted third party, its role is limited to providing physical 
security for the servers. Thus, the third party does not need any expertise beyond server 
hosting. For the supplier, scenario A has the disadvantage that the encrypted source 
code has to be sent to the third party, and thus, to leave the supplier site. 

B Ama is physically located at the site of the supplier, but in a sealed location or 
box whose integrity is assured through (i) regular checks by the customer, (ii) a 
third party, (iii) a traditional alarm system, or (iv) the use of sealed hardware. All 
communication channels of Ama are hardwired to the communication filter of the 
supplier. 

In scenarios B(ii) and B(iii), the third party again plays a very limited role in that it 
only ensures physical integrity of the amanat. The reader may object to scenario B that 
the supplier may break the seal and cheat the customer for a certain time, i.e., until the 
next routine check. We believe that the application area of our protocol invalidates this 
objection; we argue that in contrast to regular internet protocols for e.g. electronic com- 
merce, the supplier cannot gain a realistic advantage by breaking the physical integrity 
of the amanat: First of all, the application area of our protocols does not allow an instan- 
taneous "window of opportunity" like in electronic commerce, where a cheating party 
can transfer large amounts of money or gain control over a remote computer within a 
few (milli)seconds. Instead, it is quite likely that the project milestones agreed between 
the customer and the supplier are scheduled in such a way as to ensure that the routine 
check happens before the deployment of the end product. Since the supplier is not an 
anonymous user on the internet, but an established company which has a contract with 



the customer, we conclude that there is no rational incentive for the supplier to violate 
the contract in view of the perspicuous long term consequences. 

In summary, scenarios A and B have slight advantages for the customer and the 
supplier respectively. In view of the suppliers' reluctance to make source code available 
to third parties even in encrypted form, we believe that scenario B is more realistic in 
practice. In scenario B, the supplier has total control over the information leaving the 
production site. Thus, even without detailed understanding of the security scheme, the 
supplier's management can be convinced that no sensitive information is leaking. In 
our opinion, this simplicity of the amanat protocol is a major advantage for practical 
application. 

Organization of the Paper. In Section 2, we survey related work and discuss alterna- 
tive approaches to the amanat protocol. The protocol is described in detail in Section 3, 
and the correctness is addressed in Section 4. The paper is concluded in Section 5. 

2 Related Work and Alternative Solutions 

Motivated by problems involving computer security, system stability and legacy code, 
the last years have seen renewed activity in the analysis of executables from the ver- 
ification and programming languages community. Despite quite remarkable advances 
(see e.g. [15-18]), the computer-aided analysis of executables remains a hard problem; 
natural applications are semi-manual reverse engineering, automatic detection of low 
level errors such as memory violations, as well as malicious code detection [19, 20]. 

The technical difficulties in the direct analysis of executables are often exacerbated 
by the software authors' wish to prevent reverse engineering, or, in the case of malware, 
recognition of the malicious code. In these settings, software authors have rational in- 
centives to apply code obfuscation techniques which hinder systematic analysis of the 
executable. Although dynamic analysis [21] and black box testing [22,23] are relatively 
immune to obfuscation, they only give a limited assurance of system correctness. 

The current paper is orthogonal to executable analysis. We consider a scenario 
where the software author is willing to assert the quality of the source code by for- 
mal methods, but not willing or able to make the source code available to the customer. 
It is evident that the visibility of the source code to the amanat and the cooperation of 
the software author/supplier significantly increase the leverage of formal methods. We 
believe that this scenario is quite recent, as it reflects problems of current interest which 
we learnt from discussions with industrial partners. 

Proof-Carrying Code [24] is able to generate certificates directly from binaries, but 
only for a restricted class of safety policies. It is evident that a proof for a non-trivial 
system property will for all practical purposes explain the internal logic of the binary. 
Thus, publishing this proof is tantamount to losing intellectual property. 

On the computer security side, we have designed the protocol to employ estab- 
lished classical concepts, in particular an asymmetric encryption and signature scheme 
[25] based upon RSA [26] and SHA [27], see [14,28] for mathematical and practical 
introductions to computer security. 

We want to note that the current paper certainly takes an engineer's view on com- 
puter security. The results of the paper are highly specific to verification, as it exploits 



the conceptual difference between the source code and the executable. While we are 
aware of advanced methods such as secure multiparty computation [29] and zero- 
knowledge proofs [30], we believe that they are not practicable for our problem. To 
implement secure multiparty computation, it would be necessary to convert significant 
parts of the model checking tool chain into a Boolean circuit; given the size and com- 
plexity of model checkers, this is not a realistic option. To apply zero-knowledge proofs, 
one would require the verification tools to produce highly structured and detailed for- 
mal proofs. Except for the provers in item 2 of the list in Section 1, it is impractical to 
obtain such proofs by state of the art technology. More generally, we believe that any 
advanced method for which secrecy is not intuitively clear to the supplier will be hard 
to establish in practice. Thus, we are convinced that the conceptual simplicity of our 
protocol is an asset for practical applicability. 

3 The Amanat Protocol 

Following our discussion above, the amanat protocol aims to resolve the conflict be- 
tween the code customer Cus who wants to verify the source code, and the code sup- 
plier Sup who needs to protect its IP. To this end, the amanat Ama computes a certificate 
which must have enough information to assure the correctness of the program. On the 
other hand, to secure the IP of Sup, the certificate must not reveal any information 
beyond the intentionally communicated correctness properties. 

3.1 Requirements and Tool Landscape 

In order to make the protocol requirements more precise, we will now fix some notation 
and assumptions about the tool landscape. Note that all tools are publicly available to 
all involved parties. 

- The compiler Compiler takes an input source and computes an executable exec = 
Compiler(source). Note that Compiler does not take any other input. In practice, 
this means that source can be thought of as a directory tree containing a make 
file, and Compiler stands for the tool chain composed of the make command, the 
compiler, the linker etc. 

- The verification tool Verifier also takes the input source and computes two veri- 
fication verdicts, logs up and logc us - Here, logs up is the "internal" verdict for the 
supplier which may contain, for example, detailed IP-critical information such as 
counterexamples or witnesses for certain properties. The second output logc us in 
contrast contains only uncritical verification verdicts about which Sup and Cus have 
agreed beforehand. 

Similar as for the compiler, we assume that Verifier does not take any other input 
parameters. In particular, this means that the specifications are part of source, i.e., 
they are agreed between the parties and output into logc us together with the verifi- 
cation result. Moreover, all auxiliary information necessary for a successful run of 
Verifier- command line parameters, code annotations, abstraction functions etc. - 
are provided by Sup as part of source. 



Before we formally describe the cryptographic primitives for signing and verifying 
messages, we note that the underlying algorithms are not deterministic but randomized. 
This randomization is a countermeasure to attacks which exploit algebraically related 
messages, see for example [31]. In most applications, the randomization is not impor- 
tant for the protocol, as each participant can locally generate random values. In our 
protocol however, we have to make sure that the signatures generated by Ama do not 
contain hidden information for Cus. The way for Ama to leak information to Cus would 
be to replace the random bits by specifically chosen bits which describe (part of) the 
source code, similar to steganography [32]. Then, Cus could try to reconstruct the bits 
from the received message. To exclude this possibility, our protocol will enforce Ama 
to commit its random bits before it sees the source code. Thus, in our description of the 
cryptographic primitives, we have to treat the random values explicitly. 

We also note that in our discussions of randomized algorithms, we usually describe 
the behavior of the algorithm as it occurs in all but a negligible fraction of the executions 
of the algorithm [28]. 

- All parties employ the same asymmetric encryption and signing scheme [25] which 
is based upon RSA [26] and SHA [27]. Given a key pair (K pr i, K pu b) and a mes- 
sage to, we write c = K pu b (to) for the encryption of to with key K pu b yielding 
the cipher text c. Similarly, to = K pr i (c) denotes the decryption of the cipher text 
c with key K pr i resulting again in the original message to. Furthermore, we write 
s = cs\gn(K pr i, to, R) for the signature s of a message m signed with key K pr i 
and generated with random seed R. If a signature s is valid and has been generated 
with seed R, then cvei-ify^^, m , s, R) will succeed and fail otherwise. In situa- 
tions where the random seed is of no concern, we can also use cver\fy(K pu b, to, s) 
which succeeds if s is a valid signature. 3 The algorithms for encryption, decryption, 
signature generation and signature verification are assumed to require polynomial 
time with respect to the length of their inputs. 

- Communication Channels. We assume that the channels between Sup, Cus and 
Ama are secure, i.e., the protocol is not concerned with eavesdropping on these 
channels. Moreover, all ingoing and outgoing information for Ama is controlled by 
Sup, i.e., Sup can manipulate all data exchanged between Ama and Cus. 

Having fixed the environment and the notation, we can paraphrase the requirements 
in a more precise manner: 

1 . Conformance enables Cus to validate that exec and logc U5 have been produced from 
the same source. 

2. Secrecy prevents Cus from extracting, by any tractable process, any IP of Sup ex- 
cept exec and logcus- 

We note that some of the possible verification tasks discussed in Section 1 - in par- 
ticular 7, 10, 11, 12 - are concerned with non-functional properties of the source code 
which do not affect the executable produced by the compiler. The conformance prop- 
erty proves to the customer that at the time of compilation, a source with the required 

3 Note that the existence of the former 4-parameter variant of cverify is specific to the chosen 
scheme [25]. 



properties did exist. Thus, in the case of a legal conflict, a court can require the supplier 
to provide a source code which (i) compiles into the purchased executable, and (ii) pro- 
duces the same verification output logcus- There is no mathematical guarantee however, 
that the revealed code will be identical to the original code. This stronger property can 
be easily achieved by requiring Verifier to compute a hash of source, and output it into 
logcus- 

3.2 Summary Description of the Protocol 

Our protocol is based on the principle that Cus trusts Ama, and thus, Cus will believe 
that a verification verdict logcus originating from Ama is conformant with a correspond- 
ing binary exec. Thus, Cus and Sup install Ama at Sup's site such that Sup can use Ama 
to generate trusted verification verdicts subsequently. On the other hand, Supcontrols 
all the communication to and from Ama and therefore Sup is able to prohibit the com- 
munication of any piece of information beyond the verification verdict, i.e., Sup can 
enforce the secrecy of its IP. 

To ensure that Sup does not alter the verdict of Ama, Ama signs the verdicts with 
a key which is only known to Ama and Cus but not to Sup. Also, to ensure that the 
tools Compiler and Verifier given to Ama are untampered, Sup must provide certificates 
which guarantee that these tools have been approved by Cus. 

A protocol based on this simple idea does indeed ensure the conformance property, 
but a naive implementation with common cryptographic primitives may fail to guaran- 
tee the secrecy property: As argued above, the certificates generated by Ama involve 
random seeds, and Sup cannot check that these random seeds do not carry hidden in- 
formation. In our protocol, to prohibit such hidden transmission of information, Ama is 
not allowed to generate the required random seeds after it has accessed source. Instead, 
Ama generates a large supply of random seeds before it has access to source, and sends 
them to Sup. In this way, Ama commits to the random seeds, because later, Sup will 
check that Ama actually uses the random values which it has sent before. Thus, Ama is 
not able to encode any information about source into these seeds. 

The only remaining problem is that Sup is not allowed to know the random seeds 
in advance, since it could use this knowledge to compromise the cryptographic security 
of the certificates computed by Ama. Thus, Ama encrypts the random seeds before 
transmitting them to Sup. Each random seed is encrypted with a specific key, and each 
time a random seed is used by Ama, the corresponding key is revealed to Sup. 

This concludes the Amanat protocol, which guarantees conformance and secrecy at 
same time. In the next section, we present the protocol in detail. 

3.3 Detailed Protocol Description 

In the following, we present the protocol in detail in a step-wise manner. Our proto- 
col consists of three phases, namely the installation, the session initialization, and the 
certification. 



Installation Phase. During the installation phase, Cus initializes Ama with a master 
key pair (-Kqj S , Kp^ b ) which will be used later to exchange a session key pair. Then, 
Ama is transported to and installed at Sup's site. All further communication between 
Ama and Cus will be controlled by Sup. 

11 Master Key Generation [Cus] 

Cus generates the master keys (Kq^ s , K^ b ) and initializes Ama with (K™ us , K^ ub ). 

12 Installation of the Amanat [ Sup, Cus 7 

Ama is installed at Sup's site and Sup receives Kp^ b . 

Session Initialization Phase. After installation, Sup and Cus must agree on a specific 
Verifier and Compiler for analyzing and compiling source. Once Verifier and Compiler 
have been fixed, the session initialization phase starts: First, Cus generates a new pair of 
session keys (Kqus, -Kpub) and sends them to Ama via Sup. Then, the new session keys 
are used to produce certificates cert verifier and certcompiier for Verifier and Compiler, 
respectively. Sup checks the contents of the certificates and uses them, if they are indeed 
valid certificates for Verifier and Compiler, to setup Ama with Verifier and Compiler. 
Ama in turn checks again the certificates and accepts Verifier and Compiler if their 
certificates are valid. 

In the last step of the initialization, Ama generates a supply of random seeds 
R\ , . . . , Rf for t subsequent executions of the certification phase. It also generates a se- 
quence of key pairs (KRq us , KR Pub ), . . . , (KRq us , KR Pub ) for each random seed 
Ama finally encrypts each random seed to obtain and send KR Pub (Ri) to Sup. Ama 
and Sup both keep a variable round which is initialized to and will be incremented by 
1 for each execution of the certification phase. 

51 Session Key Generation 7 Cus, Sup/ 

Cus generates the session keys (i^Cus, -Kpub) and sends Kfil b (Kc U5 ) and K Pu t, to 
Sup. Sup forwards Kp^ b (KQ U5 ) and/fp^ unchanged to Ama. 

52 Generation of the Tool Certificates [Cus] 
Cus computes the certificates 

- certverifier = csign(_R'cu5, Verifier) and 

- certcompiier = csign (if C us , Compiler). 
Cus sends both certificates to Sup. 

53 Supplier Validation of the Tool Certificates [Sup] 

Sup checks the contents of the certificates, i.e., Sup checks that 

- cverify(iTp u b, Verifier, certverifier) and 

- cverify(ii'p l ib, Compiler, certcompiier) succeed. 
If one of the checks fails, Sup aborts the protocol. 

54 Amanat Tool Transmission [Sup] 

Sup sends to Ama both Verifier and Compiler as well as the certificates certverifier 
and certcompiier- 

55 Amanat Validation of the Tool Certificates [ Ama ] 

Ama checks whether Verifier and Compiler are properly certified, i.e., it checks 
whether 

- cverify(i ; fp L ,b, Verifier, certverifier) and 



- cverify(_ftTp u b, Compiler, certcompiier) succeed. 

If this is not the case, then Ama refuses to process any further input. 
S6 Amanat Random Seed Generation [ Ama ] 
Ama generates 

- a series of random seeds R\ , . . . , R t together with a series of corresponding 
key pairs {KR} Qvs , KR Pub ), {KRq us , KR Pub ), 

- encrypts the random seeds with the corresponding keys KR l Pub (Ri) for i = 
1, . . . ,t, and 

- initializes round counter round = 0. 

Ama then sends all KR l Pub {Ri) and KR Pub for i = 1, . . . ,t to Sup. 

Certification Phase. Ama is now ready for the certification phase, i.e., it will accept 
source and produce a certified verdict on source which can be forwarded to Cus and 
whose trustworthy origin can be checked by Cus. 

During certification, Ama runs Verifier and Compiler on source, generates a cer- 
tificate cert for the output logc us dedicated to Cus. The certificate is based upon the 
random seed i? r0 und which Ama committed to use in this round of the certification pro- 
tocol during the session initialization phase. Ama sends the certificate cert, the outputs 
logsup and logcus, and the key KR™" d to Sup. 

First, Sup computes the random seed R round = KR r ^" d (KR Pub (R round )) which 
Ama supposedly used for the generation of cert. Then Sup checks that the certificate 
cert is indeed a valid certificate and is based upon the random seed -R r0 und- If this is the 
case, i.e., the certificate is valid and is generated based on the predetermined random 
seed, then Ama cannot hide any unintended information in the certificates. If the checks 
fails, Sup aborts the protocol. Depending on the output of the Verifier, Sup decides 
whether to forward the results to Cus or whether to abort the certification phase. Finally, 
Cus checks the authentic origin of output logc us using cert. 

CI Source Code Transmission [Sup] 

Sup sends source to Ama. 
C2 Source Code Verification by the Amanat [ Ama ] 

Ama computes 

- the verdict (logs up , logcus) = Verifier(source) of Verifier on source, 

- the binary exec = Compiler(source), and the certificate 

- increments the round counter round, and 

- computes cert = csign(.Kcus, (exec, log Cu s) , R ro und)- 
Ama sends exec, logs up , logcus, cert, and KR™" d to Sup. 

C3 Secrecy Validation [Sup] 

Upon receiving exec, logs up , logcus, cert, and KR™^, Sup 

- decrypts the random seed R rolsnd = KR r ^ s nd (KR r ^ b nd (R round )), and 

- verifies that cverify(_R'p L ,b, (exec, logcus) , cert, R r0 und) succeeds. 

If the checks fails, Sup concludes that the secrecy requirement was violated, and 
refuses to further work with Ama. 

Otherwise, Sup evaluates logcus and logs up and decides whether to deliver the bi- 
nary exec, logcus, and cert to Cus in step C4 or whether to abort the protocol. 



C4 Conformance Validation [ Cus ] 

Upon receiving exec, logc us , and cert, Cus verifies that 
cverify^pub, (exec, logcus) , cert) succeeds. 

If the checks fails, Cus concludes that the conformance requirement was vio- 
lated, and refuses to further work with Sup. 

Otherwise Cus evaluates the contents of logc us and decides whether the verification 
verdict supports the purchase of the product exec. 

4 Protocol Correctness 

In this section, we prove conformance and secrecy of our protocol using standard cryp- 
tographic assumptions. Following [14], we assume that the public -key encryption is se- 
mantically secure and that the used signature scheme is secure against adaptive chosen 
message attacks, such as the RSA-based scheme proposed in [25]. We briefly introduce 
these security properties: 

1. Semantic security means that whatever can be learnt from the ciphertext within 
probabilistic polynomial time, can be computed, again within probabilistic polyno- 
mial time, from the length of the plaintext alone. Formally, semantic security means 
that each probabilistic polynomial time algorithm which takes as arguments a se- 
curity parameter, a public key, a number of messages encrypted with this key, the 
respective messages lengths, and any further partial information on the messages, 
can be replaced by another probabilistic polynomial time algorithm which only re- 
ceives the security parameter, the message lengths, and the partial information on 
the messages [14]. In other words., no probabilistic polynomial time algorithm can 
extract any information from a set of encrypted messages. 

2. An adaptive chosen message attack is an attack against a signature scheme, where 
the attacker has access to an oracle which can sign arbitrary messages, and uses this 
ability to sign some new message without consulting the oracle. 

More formally, a signing oracle S[Kq u ^\ with private key Kq U5 is a function which 
takes a message m and returns a signature s = csigr^ifcus, to, R) for a uniformly 
and randomly chosen random seed R. An attack is a forging algorithm F which 
(i) knows the public key Kp u t, and (ii) has access to the signing oracle S^iTcus], 
where Kq us is the private key corresponding to itp u t>. The algorithm F is allowed 
to query S[Kq us ] for an arbitrary number of signatures. F can adaptively choose 
the messages to be signed, i.e., each newly chosen message can depend on the out- 
come of the previous queries. At the end of the computation, a successful attack F 
must output a message m and a signature s such that cverify(_R'p L ,b, to, s) succeeds, 
although to has never been sent to S[Kq us \. 

A signature scheme is secure against adaptive chosen message attacks, if there is 
no probabilistic polynomial time algorithm F which has a non-negligible success 
probability. 

Theorem 1 (Conformance). If the protocol terminates (in Step C4 of the certification 
phase) with the customer Cus accepting the binary exec and the output file logcus, then 
exec and logcus must be produced from the same source in all but a negligible fraction 
of the protocol executions ( under standard cryptographic assumptions). 



Proof Sketch. Towards a contradiction, we assume that with non-negligible probability, 
Sup can forge a certificate which is accepted by Cus in step C4. Thus, Sup computes 
a certificate cert for a pair (exec, logc us ) which has not been signed by Ama but is 
accepted by Cus. Using semantic security, we show that such a malicious instance MSup 
of Sup gives rise to a forging algorithm F which implements a successful adaptive 
chosen message attack. This implies that the underlying signature scheme is not secure 
against adaptive chosen message attacks — which is a contradiction. □ 
Due to space restrictions, a more extensive proof is deferred to the appendix. We 
now turn to secrecy, which, not surprisingly, is quite straight forward to prove. 

Theorem 2 (Secrecy). By the execution of the protocol, Cus cannot extract any piece 
of information on the source source which is not contained in exec and logcus- 

Proof. During the execution of the protocol, Cus receives the binary exec, the output 
file log^s, and the certificate cert. The certificate cert = csign(ifcus, (exec, logc us ), Rj) 
can be generated from exec, logcus, the key Kq us , and the underlying random seed 
Ri. Cus generates Kq us itself and obtains access to exec and to logc us - Thus the only 
additional information communicated from Ama to Sup is the underlying random seed 
Ri. But this random seed Ri has been fixed by Ama before having access to source, 
and consequently Ama cannot encode any information on the source source which is 
not contained in exec and logc us into the certificate. □ 

5 Conclusion 

We have introduced the amanat protocol which facilitates software verification without 
violating IP rights on the source code. While the original motivation for this work stems 
from outsourcing scenarios for embedded systems and operating systems, we envision 
wider applications of our protocol for commercial-off-the-shelf software - in partic- 
ular, we are considering certification agencies which provide commercial verification 
services by enacting the customer part of the amanat protocol. 

Acknowledgments. We are thankful to Byron Cook for discussions on the device driver 
scenario. 
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Appendix: Proof of Theorem 1 



Let us first recall the general structure of the proof: We assume that the statement of 
the theorem is not true: Thus, the protocol does not enforce conformance, i.e., Sup can 
produce forged certificates using a probabilistic polynomial time algorithm which is 
successful in a non-negligible fraction of the protocol executions. In other words, with 
non-negligible probability, Sup can forge a certificate which is accepted by Cus in step 
C4. Thus, Sup must return a certificate cert for a pair (exec, logcus) which has not been 
signed by Ama, i.e., cert has not been generated by Ama. Nevertheless, by assumption, 
Cus must accept (exec, logcus) and cert. 

We describe the computations of such a malicious instance of Sup with a proba- 
bilistic polynomial time procedure MS up. 

Using semantic security, we show that such a malicious instance MSupofSup gives 
rise to a forging algorithm F which implements a successful adaptive chosen message 
attack: F is started with the public key K Pub and obtains a number of signatures for 
adaptively chosen messages and returns in probabilistic polynomial time a message m 
and a forged signature s for m. This implies that the underlying signature scheme is not 
secure against adaptive chosen message attacks — which is a contradiction. 

As starting point for such an attack algorithm F, we use a malicious instance MSup 
of Sup. Since the input/output behavior of MSup has to conform to the protocol, we 
can describe the input and output parameters of MSup as follows. The inputs of MSup 
contain every piece of information communicated to Sup during the protocol execution 
so far: 

- The encrypted random seeds KR Puh (Ri) and the respective public keys KR Pub 
with i = 1, . . . , t which have been sent to Sup in step S6. 

- The accumulated inputs source, exec, logs up , logcus, cert, and sent to Sup 
at the end of step C2 of all previous certification phases. 

- The remaining initialization messages of the session initialization phase (we do not 
refer to these arguments explicitly since they are unimportant for what follows). 

We observe that MSup receives for i = 1, . . . round the encrypted seed KR Pub (Ri) 
as well as the key pair (KR' l Cus , KR Pub ). Based on these inputs, MSup computes the 
following outputs: 

- The outputs logcus, exec, and cert which are sent to Cus at end of step C3. If Sup 
is honest, these outputs are identical to the respective inputs coming from Ama. 

- The decision whether to start another certification phase, and if so, the correspond- 
ing source to be certified by Ama. 

Note that the intended usage of MSup in the certification phase of the protocol is as fol- 
lows: To generate the first source to be certified, we call MSup only with the encrypted 
random seeds KR l Pub {Ri) and the public keys KR Pub for i = 1, . . . , t as arguments. 
Then, after step C2, MSup is called with KR Pub (Ri) and KR Pub for i = 1, . . . , t, and 
with source, exec, logs up , logcus, cert, and KRq us as arguments. If MSup decides to 
start another certification phase, it generates a new source, which is given Ama for cer- 
tification (steps CI and C2). Upon receiving the resulting exec, logs up , logc us , cert, and 



KRq us from Ama, MSup is called again, this time with two sources, two binaries, two 
output files for Sup and Cus, respectively, two certificates, and KRq us and KRq us . This 
process is continued until MSup decides to send exec, logcus, and cert to Cus. 

Since we assume that the malicious instance MSup of Sup is cheating successfully 
in a non-negligible fraction of all cases, MSup must produce a forged certificate in a 
non-negligible fraction of all cases. 

In the remainder of the proof, we construct the attack algorithm F. By the definition 
of semantic security, there must be a probabilistic polynomial time procedure MSup' 

- which computes the same result as MSup in all but a negligible fraction of the cases, 
but 

- which does not receive the encrypted seeds KR l Pub (Ri) and the keys KR Puh for 
i = round + 1, . . . , t. It still does receive the seeds KR Puh (Ri) and the keys KR Pub 
for i = 1, . . . , round. 

In particular, since MSup must produce a forged certificate in a non-negligible faction 
of all cases, the same must be true for MSup'. 

Having MSup', we can build our attack procedure F. F must simulate the protocol 
such that F can provide MSup' with all parameters as they would occur in a real proto- 
col execution. Thus, we have to simulate Ama by executing Verifier and Compiler and 
using signing oracle S^-Kicus] to obtain the corresponding certificate cert. 

Fl First Source Code Computation 

Compute the first source with MSup'Q. Set round = 1. 
F2 Simulate Ama 

Compute (logsup, logcus) = Verifier(source) and exec = Compiler(source). 
Send (logcus, exec) to the signing oracle S^-ftTcus] to obtain cert = 
csign(ifcus, (logcus, exec), R) for some uniformly and randomly chosen random 
seed R. 

F3 Generate Surrogate Key Pair 

Generate a key pair {KR r £™ d , KR'™ b nd ). 
F4 Forge Certificate 
Call MSup' with 

- KR Puh (Ri) and the key pairs (KR l Cus , KR Pub ) for i = 1, . . . , round where Ri 
is the random seed used for the ith certificate, and with 

- the source, exec, logs up , logcus, and cert of each round 1, . . . , round. 

If MSup' decides to abort the protocol and restart the certification phase with a new 
source source, then the procedure F continues at step F2. Otherwise F terminates 
and returns (exec, logc U5 ) and cert as output by MSup'. 

Since MSup' is forging certificates with a non-negligible probability, and since F 
provides MSup' with the same parameters as they would occur in a real protocol exe- 
cution, F must also produce forged certificates with a non-negligible probability. 

But since the signature scheme is secure against adaptive chosen message attacks, 
no such algorithm F can exist. □ 



